이미지
매일 쓰기 좋은 Claude Code 팁과 모범 사례 50가지
여러분은를 꽤 오래 써 봐서 잘 작동한다는 걸 알고 있고, 이제는 찾을 수 있는 모든 우위를 노리고 있을 겁니다. 사용한 지 일주일이 됐든 몇 달이 됐든 도움이 될 만한 Claude Code 모범 사례와 팁 50가지를 정리했습니다. Anthropic의 공식 문서, 이 도구를 만든 Boris Cherny, 커뮤니티 경험, 그리고 저 자신의 1년간 일상 사용 경험에서 뽑아냈습니다.

1. cc 별칭(alias) 설정하기

저는 모든 Claude Code 세션을 이렇게 시작합니다. 다음을 여러분의~/.zshrc(또는 ~/.bashrc)에 추가하세요:
bash
alias cc='claude --dangerously-skip-permissions'
그런 다음 source ~/.zshrc를 실행해 불러옵니다. 이제 claude 대신 cc를 입력하면 모든 권한 확인 프롬프트를 건너뜁니다. 이 플래그 이름은 의도적으로 무섭게 지어졌습니다. Claude Code가 여러분의 코드베이스에 무엇을 할 수 있고 실제로 무엇을 할 것인지 완전히 이해한 후에만 사용하세요. 이 내용과 더 많은 별칭은 에서 다뤘습니다.

2. ! 접두사로 bash 명령을 인라인 실행하기

!git status 또는 !npm test처럼 입력하면 명령이 즉시 실행됩니다. 명령과 그 출력이 컨텍스트에 남기 때문에 Claude가 결과를 보고 바로 이어서 작업할 수 있습니다. Claude에게 명령을 실행해 달라고 부탁하는 것보다 빠릅니다.

3. Esc로 Claude를 중단하고, Esc+Esc로 무엇이든 되돌리기

Esc는 컨텍스트를 잃지 않고 작업 중인 Claude를 멈춥니다. 곧바로 방향을 바꿀 수 있습니다.
Esc+Esc(또는/rewind)는 Claude가 만든 모든 체크포인트를 스크롤 가능한 메뉴로 보여줍니다. 코드, 대화, 혹은 둘 다 복원할 수 있습니다. "방금 것 취소해"라고 말해도 동작합니다. 복원 옵션은 네 가지입니다: 코드와 대화 모두, 대화만, 코드만, 또는 특정 체크포인트부터 요약하기.
이 덕분에 40% 정도만 확신이 드는 접근도 시도해 볼 수 있습니다. 잘되면 좋고, 안 되면 되돌리면 됩니다. 피해가 전혀 없습니다. 단, 주의할 점이 하나 있습니다. 체크포인트는 파일 편집만 추적합니다. bash 명령(마이그레이션, 데이터베이스 작업 등)으로 인한 변경은 기록되지 않습니다.
멈췄던 지점부터 이어가려면,claude --continue는 가장 최근 대화를 이어가고,claude --resume 는 세션 선택기를 엽니다.

4. Claude가 스스로 결과물을 점검할 수 있는 수단 주기

Claude가 자기 실수를 스스로 잡아낼 수 있도록 피드백 루프를 만들어 주세요. 프롬프트에 테스트 명령, 린터 검사, 기대 출력 등을 포함시키면 됩니다.
markdown
Refactor the auth middleware to use JWT instead of session tokens.
Run the existing test suite after making changes.
Fix any failures before calling it done.
Claude는 테스트를 돌리고, 실패를 확인하고, 여러분이 개입하지 않아도 고쳐냅니다. Boris Cherny는. UI 변경의 경우에는를 설정하면 Claude가 브라우저를 열고 페이지와 상호작용하면서 UI가 의도대로 작동하는지 검증할 수 있습니다. 이 피드백 루프는 단위 테스트가 놓치는 문제를 잡아냅니다.

5. 사용하는 언어의 코드 인텔리전스 플러그인 설치하기

LSP 플러그인은 파일 편집이 일어날 때마다 Claude에게 자동 진단을 제공합니다. 타입 오류, 사용하지 않는 import, 누락된 반환 타입 등을 Claude가 여러분이 눈치채기도 전에 발견하고 고칩니다. 설치할 수 있는 플러그인 중 가장 효과가 큰 단일 플러그인입니다.
여러분의 언어에 맞는 것을 골라 설치 명령을 실행하세요:
bash
/plugin install typescript-lsp@claude-plugins-official
/plugin install pyright-lsp@claude-plugins-official
/plugin install rust-analyzer-lsp@claude-plugins-official
/plugin install gopls-lsp@claude-plugins-official
C#, Java, Kotlin, Swift, PHP, Lua, C/C++용 플러그인도 제공됩니다. /plugin을 실행한 뒤 Discover 탭으로 가면 전체 목록을 볼 수 있습니다. 여러분의 시스템에 해당 언어의 언어 서버 바이너리가 설치되어 있어야 합니다(누락된 경우 플러그인이 알려줍니다).

6. gh CLI를 쓰고, Claude에게 어떤 CLI 도구든 가르치기

는 별도의 MCP 서버 없이 PR, 이슈, 댓글을 처리합니다. CLI 도구는 도구 스키마를 컨텍스트 창에 올리지 않기 때문에 MCP 서버보다 컨텍스트 효율이 좋습니다. jq, curl 같은 다른 표준 CLI 도구에도 같은 얘기가 적용됩니다.
Claude가 아직 모르는 도구에 대해서는 이렇게 말하면 됩니다: "'sentry-cli --help'를 실행해서 사용법을 익힌 뒤, 그걸 이용해 프로덕션의 가장 최근 에러를 찾아줘." Claude는 help 출력을 읽고 문법을 파악한 뒤 명령을 실행합니다. 사내에서만 쓰는 마이너한 CLI도 잘 동작합니다.

7. 복잡한 추론에는 "ultrathink"를 추가하기

이것은 effort를 high로 설정하고 Opus 4.6에서 적응형 추론을 활성화하는 키워드입니다. Claude는 문제에 따라 생각하는 양을 동적으로 배분합니다. 아키텍처 결정, 까다로운 디버깅, 다단계 추론처럼 Claude가 행동하기 전에 깊이 생각해야 하는 상황에 쓰세요.
또한/effort로 effort를 영구적으로 설정할 수도 있습니다. 덜 복잡한 작업이라면 낮은 effort 레벨이 빠르고 저렴합니다. 문제에 맞게 effort를 조절하세요. 변수 이름 바꾸기에 사고 토큰을 태울 이유가 없습니다.

8. 필요할 때만 불러오는 지식, 스킬(Skills) 활용하기

스킬은 필요할 때마다 Claude의 지식을 확장하는 마크다운 파일입니다. 세션마다 항상 로드되는와 달리, 스킬은 현재 작업과 관련이 있을 때만 로드됩니다. 덕분에 컨텍스트를 가볍게 유지할 수 있습니다.
스킬은.claude/skills/에 직접 만들거나, 미리 만들어진 스킬을 제공하는 플러그인을 설치하면 됩니다(/plugin을 실행해 어떤 스킬이 있는지 둘러볼 수 있습니다). API 관례, 배포 절차, 코딩 패턴처럼 Claude가 가끔씩만 필요로 하는 전문 도메인 지식에 스킬을 활용하세요.

9. 휴대폰에서 Claude Code 제어하기

claude remote-control을 실행해 세션을 시작한 다음,나 iOS/Android의 Claude 앱에서 그 세션에 접속하세요. 세션은 여러분의 컴퓨터에서 로컬로 실행됩니다. 휴대폰이나 브라우저는 그것을 들여다보는 창에 불과합니다. 어디서든 메시지를 보내고, 도구 호출을 승인하고, 진행 상황을 확인할 수 있습니다.
팁 #1의cc 별칭을 사용하고 있다면 Claude는 이미 전체 권한을 가지고 있어서 행동마다 승인을 받을 필요가 없습니다. 그래서 원격 제어가 한층 매끄러워집니다. 작업을 시작해 두고 자리를 비웠다가, Claude가 작업을 끝내거나 예상치 못한 상황이 발생했을 때만 휴대폰으로 확인하면 됩니다.

10. 컨텍스트 창을 100만 토큰까지 확장하기

Sonnet 4.6와 Opus 4.6 모두 100만 토큰 컨텍스트 창을 지원합니다. Max, Team, Enterprise 요금제에서는 Opus가 자동으로 100만 컨텍스트로 업그레이드됩니다. 세션 도중에도/model opus[1m] 또는 /model sonnet[1m]로 모델을 전환할 수 있습니다.
큰 컨텍스트에서 품질이 걱정된다면 500k부터 시작해서 점진적으로 늘려가세요. 컨텍스트가 클수록 컴팩션이 시작되기 전까지의 여유 공간이 늘어나지만, 작업에 따라 응답 품질이 달라질 수 있습니다.CLAUDE_CODE_AUTO_COMPACT_WINDOW로 컴팩션이 언제 시작될지 제어하고,CLAUDE_AUTOCOMPACT_PCT_OVERRIDE로 퍼센트 임계값을 설정할 수 있습니다. 자기 워크플로에 맞는 최적 지점을 찾아보세요.

11. 어떻게 접근할지 확신이 없을 때는 Plan Mode 사용하기

여러 파일에 걸친 변경, 낯선 코드, 아키텍처 결정에는를 사용하세요. 약간의 오버헤드(앞단에서 몇 분 더 소요)가 있긴 하지만, Claude가 자신만만하게 잘못된 문제를 20분 동안 푸는 사태를 막아줍니다.
작고 범위가 명확한 작업에는 건너뛰어도 됩니다. 변경 내용을 한 문장으로 설명할 수 있다면 그냥 바로 처리하면 됩니다. 대화를 떠나지 않고도 언제든Shift+Tab로 Normal, Auto-Accept, Plan 권한 모드를 순환하면서 Plan Mode로 전환할 수 있습니다.

12. 관련 없는 작업 사이에는 /clear 실행하기

날카로운 프롬프트로 시작한 깨끗한 세션이, 어수선해진 3시간짜리 세션보다 낫습니다. 다른 작업이라면 먼저/clear부터 입력하세요.
진척을 버리는 기분이 든다는 건 압니다. 그래도 새로 시작하는 편이 결과가 더 좋습니다. 세션이 망가지는 이유는 이전 작업에서 누적된 컨텍스트가 지금 내리는 지시를 묻어버리기 때문입니다./clear로 비우고 집중된 시작 프롬프트를 쓰는 5초가, 점점 효과가 떨어지는 30분을 절약해 줍니다.

13. Claude 대신 버그를 해석하려 들지 말고, 원본 데이터를 그대로 붙여넣기

버그를 말로 설명하는 건 느립니다. Claude가 추측하는 걸 보고, 고치고, 그걸 반복하게 됩니다.
에러 로그, CI 출력, Slack 스레드를 그대로 붙여넣고 "고쳐"라고만 말하세요. Claude는 분산 시스템의 로그를 읽고 어디서 무너졌는지 추적합니다. 여러분이 해석을 거치는 순간 추상화가 끼어들어, 정작 근본 원인을 짚는 데 필요한 디테일이 사라집니다. Claude에게 원본 데이터를 주고 옆으로 비키세요.
CI에도 똑같이 적용됩니다. "실패한 CI 테스트 가서 고쳐 줘"라는 한마디와 함께 CI 출력을 붙여넣는 것이 가장 안정적인 패턴 중 하나입니다. PR URL이나 번호를 붙여넣고 실패한 체크를 확인해 고쳐 달라고 시킬 수도 있습니다. 팁 #6의 gh CLI가 설치되어 있다면 나머지는 Claude가 알아서 처리합니다.
터미널에서 출력을 직접 파이프로 보낼 수도 있습니다:
bash
cat error.log | claude "explain this error and suggest a fix"
npm test 2>&1 | claude "fix the failing tests"

14. 빠른 곁가지 질문에는 /btw 사용하기

/btw는 대화 기록에 추가하지 않고도 빠른 질문을 던질 수 있는 오버레이를 띄웁니다. 저는 현재 세션에 대한 확인 질문에 이걸 씁니다. "왜 이 방식을 골랐어?" 또는 "다른 옵션과의 트레이드오프는 뭐야?" 같은 식으로요. 답변은 닫을 수 있는 오버레이로 표시되고, 메인 컨텍스트는 가볍게 유지되며, Claude는 계속 작업을 진행합니다.

15. 격리된 병렬 브랜치 작업에는 --worktree 사용하기

claude --worktree feature-auth는 새 브랜치와 함께 격리된 작업 사본을 만듭니다. git worktree의 설정과 정리는 Claude가 알아서 처리해 줍니다.
Claude Code 팀은 이를라고 부릅니다. 3~5개의 worktree를 띄워 각각에서 Claude 세션을 병렬로 돌리세요. 저는 보통 2~3개를 돌립니다. 각 worktree는 자기만의 세션, 브랜치, 파일 시스템 상태를 가집니다.
로컬 worktree의 한계는 결국 여러분 컴퓨터의 한계입니다. 여러 개발 서버, 빌드, Claude 세션이 동시에 CPU를 두고 경쟁합니다. 는 각 에이전트를 브라우저 미리보기가 가능한 자체 클라우드 컨테이너로 이전시킵니다. 덕분에 여러분의 컴퓨터는 두뇌가 필요한 작업에만 집중할 수 있습니다.

16. Ctrl+S로 작성 중인 프롬프트 임시 저장하기

긴 프롬프트를 절반쯤 쓰다가 먼저 빠른 답이 필요하다는 걸 깨달은 상황이라면,Ctrl+S가 작성 중이던 초안을 임시 저장합니다. 빠른 질문을 입력해 보내고 나면, 임시 저장해 둔 프롬프트가 자동으로 복원됩니다.

17. Ctrl+B로 오래 걸리는 작업을 백그라운드로 보내기

Claude가 오래 걸리는 bash 명령(테스트 스위트, 빌드, 마이그레이션 등)을 시작했을 때Ctrl+B를 누르면 그것을 백그라운드로 보냅니다. 프로세스가 돌아가는 동안 Claude는 계속 작업을 이어가고, 여러분도 계속 대화할 수 있습니다. 프로세스가 끝나면 결과가 표시됩니다.

18. 실시간 상태 표시줄 추가하기

상태 표시줄은 Claude의 매 턴이 끝난 뒤 실행되는 셸 스크립트입니다. 터미널 하단에 현재 디렉터리, git 브랜치, 컨텍스트 사용량(창이 얼마나 찼는지에 따라 색상으로 구분) 같은 실시간 정보를 보여줍니다.
가장 빠르게 설정하는 방법은 Claude Code 안에서/statusline을 실행하는 것입니다. 무엇을 표시하고 싶은지 묻고 스크립트를 생성해 줍니다. 복사해서 붙여 넣을 수 있는 스크립트와 함께 전체 설정 과정은.

19. 서브에이전트를 활용해 메인 컨텍스트를 깨끗하게 유지하기

"서브에이전트를 사용해서 결제 플로우가 실패한 트랜잭션을 어떻게 처리하는지 알아봐 줘." 이렇게 말하면 자체 컨텍스트 창을 가진 별개의 Claude 인스턴스가 생성됩니다. 그 인스턴스가 모든 파일을 읽고, 코드베이스에 대해 추론한 뒤, 간결한 요약으로 보고합니다.
덕분에 메인 세션은 깨끗하게, 무언가를 만들 충분한 여유 공간을 유지합니다. 깊이 있는 조사 한 번이 코드를 한 줄도 쓰기 전에 컨텍스트 창의 절반을 잡아먹기도 합니다. 서브에이전트는 그 비용을 메인 세션에서 빼냅니다. 내장 유형으로는 Explore(Haiku 기반의 빠른 파일 검색)와 Plan(읽기 전용 분석)이 있습니다. 전체 그림은 가이드를 참고하세요.

20. 멀티 세션 협업을 위한 에이전트 팀

실험적이지만 강력합니다. 먼저 설정 또는 환경 변수에CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS를 추가해 활성화하세요. 그런 다음 Claude에게 팀을 만들라고 요청하세요. "이 모듈들을 병렬로 리팩터링할 팀원 3명짜리 에이전트 팀을 만들어 줘." 팀 리더가 팀원들에게 작업을 분배하고, 각 팀원은 자체 컨텍스트 창과 공유 작업 목록을 갖습니다. 팀원들은 서로 메시지를 주고받으며 직접 협업할 수 있습니다.
팀원은 3~5명, 팀원 한 명당 작업은 5~6개로 시작하세요. 같은 파일을 수정하는 작업을 배정하는 것은 피하세요. 두 명의 팀원이 같은 파일을 편집하면 덮어쓰기가 일어납니다. 병렬 구현을 시도하기 전에 리서치와 리뷰 작업(PR 리뷰, 버그 조사 등)부터 시작하세요.

21. 지시문으로 컴팩션을 안내하기

컨텍스트가 컴팩트될 때(자동으로든/compact로든), Claude에게 무엇을 보존할지 알려주세요. "/compact API 변경과 수정된 파일 목록에 집중해서 정리해 줘." 다음과 같은 상시 지시문을에 추가해 둘 수도 있습니다: "컴팩션할 때는 수정된 파일의 전체 목록과 현재 테스트 상태를 보존하라."

22. 반복 점검에는 /loop 사용하기

/loop 5m check if the deploy succeeded and report back는 세션이 열려 있는 동안 백그라운드에서 반복적으로 실행되는 프롬프트를 예약합니다. 간격은 선택 사항이며(기본값 10분),s, m, h, d 단위를 지원합니다. 다른 명령으로도 루프를 돌릴 수 있습니다: /loop 20m /review-pr 1234. 작업은 세션 범위로 동작하며 3일 후 만료되므로, 잊어버린 루프가 영원히 돌아가는 일은 없습니다. 배포 모니터링, CI 파이프라인 감시, 외부 서비스 폴링 등 다른 일에 집중하면서 백그라운드로 돌리고 싶은 작업에/loop를 사용하세요.

23. 더 풍부한 프롬프트를 위해 음성 받아쓰기 활용하기

/voice을 실행해 푸시투토크(push-to-talk)를 활성화하고,Space를 누른 채로 말하면 받아쓰기가 됩니다. 음성이 실시간으로 프롬프트에 옮겨지고, 같은 메시지 안에서 음성과 타이핑을 섞어 쓸 수 있습니다. 말로 하는 프롬프트는 자연스럽게 타이핑한 것보다 더 많은 컨텍스트를 담게 됩니다. 키 입력을 아끼려고 줄이지 않고 배경을 설명하고, 제약 조건을 언급하고, 원하는 것을 풀어서 말하기 때문입니다. 계정이 필요합니다(API 키가 아닙니다). 푸시투토크 키를meta+k처럼 모디파이어 조합으로 다시 매핑하려면~/.claude/keybindings.json에 설정해 주면 누름 감지 워밍업을 건너뛸 수 있습니다.

24. 같은 문제로 2번 교정했다면 새로 시작하기

여러분과 Claude가 계속해서 교정 작업의 토끼굴로 빠져드는데도 문제가 여전히 해결되지 않는다면, 그 시점의 컨텍스트는 이미 실패한 접근법들로 가득 차서 다음 시도를 적극적으로 방해하고 있는 상태입니다./clear로 비우고, 그동안 알아낸 내용을 반영한 더 나은 시작 프롬프트를 작성하세요. 더 날카로운 프롬프트를 가진 깨끗한 세션은, 누적된 막다른 길에 짓눌린 긴 세션보다 거의 항상 더 좋은 결과를 냅니다.

25. Claude에게 어떤 파일을 봐야 하는지 정확히 알려주기

파일을 직접 참조하려면@를 사용하세요: /middleware.ts가 세션 처리를 담당합니다.@ 접두사는 자동으로 파일 경로로 해석되므로, Claude는 정확히 어디를 봐야 할지 알게 됩니다.
Claude는 스스로 grep과 코드베이스 검색을 할 수 있지만, 후보를 좁혀 가며 적절한 파일을 식별하는 과정을 거쳐야 합니다. 검색 단계마다 토큰과 컨텍스트가 소모됩니다. 처음부터 올바른 파일을 가리키면 그 과정을 통째로 건너뛸 수 있습니다.

26. 낯선 코드는 모호한 프롬프트로 탐색하기

"이 파일에서 뭘 개선하고 싶어?"는 훌륭한 탐색용 프롬프트입니다. 모든 프롬프트가 구체적일 필요는 없습니다. 기존 코드에 새로운 시각이 필요할 때, 모호한 질문은 여러분이 물어볼 생각조차 못 했던 것들을 Claude가 끄집어낼 여지를 줍니다.
저는 낯선 저장소에 새로 합류했을 때 이 방법을 씁니다. Claude는 제가 처음 훑어볼 때는 놓칠 만한 패턴, 불일치, 개선 기회를 짚어 줍니다.

27. Ctrl+G로 계획 편집하기

Claude가 계획을 제시했을 때Ctrl+G를 누르면 텍스트 에디터에서 계획을 열어 바로 편집할 수 있습니다. Claude가 코드 한 줄 쓰기 전에 제약 조건을 추가하고, 단계를 빼고, 접근 방향을 바꿀 수 있습니다. 계획이 대체로 맞지만 전체를 다시 설명하지 않고 몇 단계만 손보고 싶을 때 유용합니다.

28. /init를 돌린 다음, 결과물을 절반으로 줄이기

는 프로젝트 루트에 두는 마크다운 파일로, Claude에게 빌드 명령, 코딩 표준, 아키텍처 결정, 저장소 관례 같은 영구적인 지시를 제공합니다. Claude는 모든 세션을 시작할 때 이 파일을 읽습니다./init는 프로젝트 구조를 기반으로 시작용 버전을 생성합니다. 빌드 명령, 테스트 스크립트, 디렉터리 구조 같은 정보를 자동으로 수집합니다.
생성 결과는 대체로 부풀려져 있습니다. 어떤 줄이 왜 거기 있는지 설명할 수 없다면 지우세요. 잡음은 잘라내고 빠진 것을 채워 넣으세요. 이 파일들을 어떻게 구조화할지에 대해 더 알고 싶다면 글을 참고하세요.

29. 모든 줄에 적용할 리트머스 시험

여러분의의 모든 줄에 대해 이렇게 자문해 보세요. "이게 없으면 Claude가 실수할까?" Claude가 이미 알아서 올바르게 한다면 그 지시는 잡음입니다. 불필요한 줄 하나하나가 정작 중요한 줄들을 희석시킵니다. 준수율이 떨어지기 시작하기 전까지 대략 150~200개 정도의 지시 예산이 있는데, 시스템 프롬프트가 이미 그중 약 50개를 사용하고 있습니다.

30. Claude가 실수했을 때 "다시는 같은 일이 없도록 너의 를 업데이트해"라고 말하기

Claude가 실수를 했을 때, "이런 일이 다시 일어나지 않도록 파일을 업데이트해 줘"라고 말하세요. Claude는 자기가 지킬 규칙을 직접 작성합니다. 다음 세션부터는 자동으로 그 규칙을 따릅니다.
시간이 지나면서 여러분의 는 실제 실수들을 통해 다듬어지는 살아있는 문서가 됩니다. 무한정 커지지 않도록 (팁 #32 참고)를 사용해.md처럼 패턴과 해결책을 모아 둔 별도 파일을 참조하게 하세요. 그러면는 가볍게 유지되고, Claude는 필요할 때 세부 내용을 읽습니다.

31. 가끔만 적용되는 규칙은 .claude/rules/에 두기

마크다운 파일을.claude/rules/에 두면 주제별로 지시를 정리할 수 있습니다. 기본적으로 모든 규칙 파일은 세션 시작 시 로드됩니다. Claude가 특정 파일을 작업할 때만 규칙이 로드되도록 하려면paths 프런트매터를 추가하세요:
yaml
---
paths:
  - "**/*.ts"
---
# TypeScript conventions
Prefer interfaces over types.
이렇게 하면 메인 를 가볍게 유지할 수 있습니다. TypeScript 규칙은 Claude가 .ts 파일을 읽을 때, Go 규칙은 .go 파일을 읽을 때 로드됩니다. 사용하지 않는 언어의 관례를 헤집고 다닐 일이 없습니다.

32.를 가볍게 유지하기

문서를 이렇게 참조할 수 있습니다:.md. 또는.md,.json, 심지어 @~/.claude/my-project-instructions.md 같은 파일도 참조할 수 있습니다.
Claude는 필요할 때만 그 파일을 읽습니다.는 매 세션마다 읽는 파일을 부풀리지 않고 "필요하면 더 참고할 컨텍스트가 여기 있어"라고 알려주는 장치라고 생각하면 됩니다.

33. /permissions로 안전한 명령을 허용 목록에 추가하기

npm run lint에 백 번째로 "승인" 버튼을 누르는 일은 그만하세요. /permissions을 사용하면 신뢰할 수 있는 명령을 허용 목록에 등록해 흐름을 끊지 않을 수 있습니다. 목록에 없는 명령에 대해서는 여전히 확인 프롬프트가 뜹니다.

34. Claude가 자유롭게 작업하길 원할 때는 /sandbox 사용하기

/sandbox를 실행하면 OS 수준의 격리를 활성화합니다. 쓰기는 프로젝트 디렉터리로 제한되고, 네트워크 요청은 여러분이 승인한 도메인으로만 허용됩니다. macOS에서는 Seatbelt를, Linux에서는 bubblewrap을 사용하므로, Claude가 만들어내는 모든 하위 프로세스에 제한이 적용됩니다. auto-allow 모드에서는 샌드박스화된 명령이 권한 프롬프트 없이 실행되며, 안전 장치를 갖춘 거의 완전한 자율성을 얻을 수 있습니다.
감독 없이 진행하는 작업(밤새 돌리는 마이그레이션, 실험적 리팩터링 등)은 Claude를 Docker 컨테이너 안에서 실행하세요. 컨테이너는 완전한 격리, 손쉬운 롤백, 그리고 몇 시간씩 Claude를 돌려도 괜찮다는 확신을 줍니다.

35. 반복되는 작업을 위한 커스텀 서브에이전트 만들기

즉석에서 서브에이전트를 띄우는 방식(팁 #19)과 달리, 커스텀 서브에이전트는.claude/agents/에 미리 구성해 저장해 둔 에이전트입니다. 예를 들어 Opus와 읽기 전용 도구만 갖춘 security-reviewer 에이전트, 또는 속도를 위해 Haiku를 쓰는 quick-search 에이전트 같은 식입니다.
/agents로 둘러보고 새로 만들 수 있습니다. 자체 파일 시스템이 필요한 에이전트에는isolation: worktree로 설정할 수 있습니다.

36. 자기 스택에 맞는 MCP 서버 고르기

먼저 시작해 볼 만한 MCP 서버는 다음과 같습니다:Playwright 는 브라우저 테스트와 UI 검증에,PostgreSQL/MySQL 은 직접 스키마 쿼리에,Slack 은 버그 리포트와 스레드 컨텍스트 읽기에,Figma 는 디자인-투-코드 워크플로에 적합합니다.
Claude Code는 동적 도구 로딩을 지원하므로, 서버는 Claude가 필요로 할 때만 자기 정의를 로드합니다. 사용 가능한 서버의 전체 목록은 가이드를 참고하세요.

37. 출력 스타일 설정하기

/config을 실행하고 원하는 스타일을 선택하세요. 내장 옵션으로는 Explanatory(자세하고 단계별 설명), Concise(간결하고 행동 중심), Technical(정확하고 전문 용어 친화적)이 있습니다.
커스텀 출력 스타일은~/.claude/output-styles/에 파일로 만들어 둘 수도 있습니다.

38.는 제안에, 훅은 필수 요구사항에

는 권고 사항입니다. Claude는 그것을 약 80%의 비율로 따릅니다. 훅은 결정론적이며 100% 실행됩니다. 예외 없이 매번 일어나야 하는 일(포매팅, 린팅, 보안 검사 등)은 훅으로 만드세요. Claude가 참고할 가이드라면로 충분합니다.

39. PostToolUse 훅으로 자동 포매팅하기

Claude가 파일을 편집할 때마다 포매터가 자동으로 실행되어야 합니다. Claude가 파일을 편집하거나 작성한 직후에 Prettier(또는 여러분이 쓰는 포매터)를 실행하는 PostToolUse 훅을 .claude/settings.json에 추가하세요:
json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \\\\"$CLAUDE_FILE_PATH\\\\" 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}
|| true는 훅 실패가 Claude를 막지 않게 해 줍니다. 다른 도구들을 이어서 붙여도 됩니다. npx eslint --fix를 두 번째 훅 항목으로 추가하는 식입니다.
같은 파일을 에디터에서 열어 두고 있다면, Claude가 작업하는 동안 저장 시 자동 포매팅(format-on-save)을 꺼 두는 것을 고려해 보세요. 일부 개발자들은 에디터 저장이 프롬프트 캐시를 무효화시켜 Claude가 파일을 다시 읽게 만들 수 있다고 보고했습니다. 대신 훅이 포매팅을 처리하도록 하세요.

40. PreToolUse 훅으로 파괴적인 명령 차단하기

Bash에 PreToolUse 훅을 걸어rm -rf, drop table, truncate 같은 패턴을 차단하세요. Claude는 시도조차 하지 않게 됩니다. 훅은 Claude가 도구를 실행하기 전에 발동되므로, 파괴적인 명령은 피해를 주기 전에 잡힙니다.
json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "type": "command",
        "command": "if echo \\\\"$TOOL_INPUT\\\\" | grep -qE 'rm -rf|drop table|truncate'; then echo 'BLOCKED: destructive command' >&2; exit 2; fi"
      }
    ]
  }
}
이 내용을 프로젝트의.claude/settings.json에 추가하세요. 대화형으로 설정하려면/hooks을 사용하거나, Claude에게 그냥 이렇게 말해도 됩니다: "rm -rf, drop table, truncate 명령을 차단하는 PreToolUse 훅을 추가해 줘."

41. 훅으로 컴팩션 전후의 중요한 컨텍스트 보존하기

긴 세션에서 컨텍스트가 컴팩트되면 Claude는 여러분이 무엇을 작업 중이었는지 놓칠 수 있습니다.compact 매처를 가진 Notification 훅을 두면 컴팩션이 일어날 때마다 핵심 컨텍스트가 자동으로 다시 주입됩니다.
Claude에게 이렇게 말하세요: "컴팩션 후에 현재 작업, 수정된 파일, 모든 제약 조건을 다시 알려주는 Notification 훅을 설정해 줘." 그러면 Claude가 여러분의 설정에 훅을 만들어 줍니다. 다시 주입하기 좋은 후보는 현재 작업 설명, 그동안 수정한 파일 목록, 절대 어기면 안 되는 제약("마이그레이션 파일은 수정하지 마") 같은 것들입니다.
여러 시간 동안 어떤 기능에 깊이 몰입한 상태라 Claude가 맥락을 놓치면 곤란한 상황에서 가장 가치 있는 기법입니다.

42. 인증, 결제, 데이터 변경은 항상 직접 검토하기

Claude는 코드를 잘 작성합니다. 하지만 이런 결정은 사람의 손이 필요합니다. 인증 플로우, 결제 로직, 데이터 변경, 파괴적인 데이터베이스 작업이 그렇습니다. 나머지 코드가 아무리 좋아 보여도 이 부분만큼은 직접 검토하세요. 잘못된 인증 스코프, 잘못 설정된 결제 웹훅, 컬럼을 조용히 떨어뜨리는 마이그레이션 한 번이 사용자, 돈, 신뢰를 잃게 만들 수 있습니다. 어떤 자동화된 테스트도 이런 문제를 모두 잡아내지 못합니다.

43. 현재 흐름을 잃지 않고 다른 접근을 시도하려면 /branch 사용하기

/branch(또는/fork)는 현재 시점에서 대화의 복사본을 만듭니다. 브랜치 안에서 위험한 리팩터링을 시도해 보세요. 잘되면 유지하면 되고, 안 되면 원래 대화는 그대로 남아 있습니다. 두 경로 모두 살아 있다는 점에서 되돌리기(팁 #3)와 다릅니다.

44. 기능 명세를 끝까지 짤 수 없을 때는 Claude가 인터뷰하게 하기

무엇을 만들지는 알지만, Claude가 잘 만들기 위해 필요한 세부 사항을 다 가지고 있지 않은 것 같다면, Claude가 질문하게 하세요.
markdown
I want to build [brief description]. Interview me in detail
using the AskUserQuestion tool. Ask about technical implementation,
edge cases, concerns, and tradeoffs. Don't ask obvious questions.
Keep interviewing until we've covered everything,
then write a complete spec to SPEC.md.
명세가 완성되면 새 세션을 시작해서, 깨끗한 컨텍스트와 완성된 명세로 작업을 진행하세요.

45. 한 Claude가 작성하고, 다른 Claude가 검토하게 하기

첫 번째 Claude가 기능을 구현하고, 두 번째 Claude는. 검토자는 구현 과정에서 어떤 지름길을 썼는지 모르므로, 그런 부분 하나하나에 의문을 제기하게 됩니다.
TDD에도 같은 아이디어가 통합니다. 세션 A가 테스트를 작성하고, 세션 B가 그 테스트를 통과시키는 코드를 작성합니다.

46. PR은 대화하듯 리뷰하기

Claude에게 한 방에 PR 리뷰를 끝내달라고 요청하지 마세요(원하면 그렇게 해도 되지만요). PR을 세션에서 열고 대화를 나누세요. "이 PR에서 가장 위험한 변경을 차근차근 설명해 줘." "이게 동시 실행되면 뭐가 깨질까?" "에러 처리가 코드베이스의 나머지 부분과 일관성이 있어?"
대화형 리뷰는 정말 중요한 부분을 깊이 파고들 수 있어서 더 많은 문제를 잡아냅니다. 한 방 리뷰는 스타일 트집을 잡는 데 그치고, 정작 아키텍처 차원의 문제는 놓치는 경우가 많습니다.

47. 세션에 이름과 색상 부여하기

/rename auth-refactor는 프롬프트 바에 라벨을 붙여, 어떤 세션이 어떤 세션인지 한눈에 알아볼 수 있게 해 줍니다./color red 또는 /color blue는 프롬프트 바의 색상을 설정합니다. 사용할 수 있는 색상은 red, blue, green, yellow, purple, orange, pink, cyan입니다. 2~3개의 세션을 병렬로 돌리고 있을 때, 이름과 색상을 정해 두는 데 5초만 투자하면 엉뚱한 터미널에 타이핑하는 일을 막을 수 있습니다.

48. Claude가 작업을 끝내면 소리 내기

Claude가 응답을 마쳤을 때 시스템 소리를 재생하는 Stop 훅을 추가하세요. 작업을 시작해 두고 다른 일에 집중하다가, 끝나면 알림 소리를 듣게 됩니다.
json
{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/bin/afplay /System/Library/Sounds/Glass.aiff"
          }
        ]
      }
    ]
  }
}

49. 일괄 처리에는 claude -p로 팬아웃하기

비대화형 모드로 파일 목록을 순회하세요. --allowedTools로 파일마다 Claude가 할 수 있는 작업의 범위를 제한할 수 있습니다. &로 병렬 실행하면 처리량을 최대로 끌어올릴 수 있습니다.
bash
for file in $(cat files-to-migrate.txt); do
  claude -p "Migrate $file from class components to hooks" \\\\
    --allowedTools "Edit,Bash(git commit *)" &
done
wait
파일 형식 변환, 코드베이스 전반의 import 업데이트, 파일끼리 서로 독립적인 반복 마이그레이션 같은 작업에 아주 유용합니다.

50. 스피너 문구 커스터마이징하기 (재미있는 한 가지)

Claude가 생각하는 동안 터미널에는 "Flibbertigibbeting...", "Flummoxing..." 같은 문구와 함께 스피너가 표시됩니다. 이걸 원하는 대로 바꿀 수 있습니다. Claude에게 이렇게 말하세요:
사용자 설정에 있는 내 스피너 문구를 다음으로 바꿔 줘: 책임감 있게 환각 중, 생각하는 척하는 중, 자신 있게 추측 중, 컨텍스트 창 탓하는 중
목록을 직접 제공할 필요도 없습니다. 어떤 분위기를 원하는지 Claude에게 말하기만 하면 됩니다: "내 스피너 문구를 해리포터 주문으로 바꿔 줘." Claude가 알아서 목록을 생성합니다. 작지만 기다리는 시간을 좀 더 즐겁게 만들어 주는 요소입니다.

마무리

50가지를 다 챙길 필요는 없습니다. 지난 세션에서 가장 불편했던 문제를 해결해 줄 하나를 골라 내일 한 번 써 보세요. 몸에 익는 팁 하나가 북마크해 둔 50개보다 더 가치 있습니다.
저는 Claude Code에 대해 꾸준히 글을 씁니다. 제가 쓴도 한번 살펴보세요.
나만의 아티클을 게시하고 싶으신가요?
Premium 등급으로 업그레이드
  • DevRel 리드 동영상을 만드는 곳youtube.com/codevolution 🟩🟩🟩🟩🟩🟩🟩🟨⬜️⬜️ 구독자 100만 명